FIG. 1A shows how a document or image is printed according to a desired set of print requirements, such as number of copies, collation, paper selection, finishing, etc. A client 12 in one example may be a Personal Computer (PC). The client 12 is connected to a printing device 14. In order for the printing device 14 to correctly print a print job 16, a user must select options from a print requirement generation process in the client 12, such as a printer driver, that is compatible with the printing device 14. Alternatively, the default settings of the printing device 14 must be set to the print requirements for the print job 16.
A print requirement may be chosen for the print job 16 that is not compatible with the printing device 14 (e.g., mismatched printer drivers). For example, the print job 16 may include print requirements for a model A printer but the print job may be sent to a model B printer. In this situation the model B printer may generate undesirable results for the print job 16. To solve the problem the firmware in the model B printer would have to be replaced with model A printer firmware 18.
FIG. 1B shows an approach where the numbering for input tray print requirements is not hard-coded into the printing device 14. Instead, the printing device 14 has loadable input tray mapping tables. The mapping tables include a mapping table 20 for the native printing device model B and a mapping table 22 for a model A printing device. The printing device 14 can then be manually set to emulate the input tray numbering for the printing devices associated with mapping tables 20 or 22.
This method has several limitations. For example, the printer only handles remapping of input trays, more specifically, where input trays are specified by a number (e.g., PCL). The printer must also have a mapping for the replacement device and must know to use the replacement device mapping prior to receiving the print job.
Many standard organizations and manufacturers have been moving towards more uniform and compatible print job control language specifications with devices from other manufacturers, such as compatibility with Hewlett Packard's device implementations of the Printer Job Language (PJL).
One method to obtain such compatibility is for a manufacturer to replace their previous job control implementation with the more uniform cross-manufacturer implementation. But, the printer manufacturer would then lose backward compatibility with its own previous printer implementation.
Therefore, there is a need for providing compatibility with a more uniform cross-manufacturer implementation of a job control language, while maintaining backwards compatibility with previous implementations. Further, there is a need to automatically detect whether the print data stream conforms to the uniform cross-manufacturer or the manufacturer's own implementation without having to manually switch between printer implementations.